Goal

The JavaServer is a dynamically configurable and extensible server technology. It supports extension through Servlets, which are used to extend the Web Server, like the way that Applets extend a Web Browser. The JavaServer provides a controlled execution environment, a Servlet Sandbox analagous to the Applet Sandbox used by Web Browsers to control applets.

Use of the JDK 1.1.2 code signing facility allows a new level of policy flexibility to be granted to the web site adminstrator. New modes of operation will be supported, so that servlets will come in four flavors:

• Trusted servlets which are granted full access to the system. There are two types of trusted servlets:
  • JavaServer-Internal Servlets ... Some parts of the JavaServer are implemented using servlets.
  • Local Servlets ... The JavaServer may be configured with a single directory of local servlets, which are provided by the site administrator. These have a class loader which reloads the servlets when they have been modified, and that class loader is recognized explicitly by the security manager.
• Signed Network Servlets ... All network servlets execute in the servlet sandbox. If the servlet was signed by one of a set of signers identified by the website administrator, the sandbox allows full access. (It can access the file system, remote hosts, and so on.) Servlets which were signed, but not by entities trusted by the website administrator, will be treated like unsigned network servlets.
• Unsigned Network Servlets ... Unsigned network servlets will be constrained by the sandbox so that they execute without privilege to access the file system, network and so on.

Trusted servlets should, of course, not abuse the trust placed in them. They have access to the server's private encryption keys, to the file system, to the network. They could even call the System.exit method.

In the future, the control granted by the sandbox should be made even more flexible. Specifically, an ACL associated with a given web server will define what basic privileges are extended to which signers, and ACL entries used to control access to web resources will be appropriately applied to requests coming through servlets. For example, on a given host the web server operating on port 80 might use a different ACL than one running on port 8080, and if the host uses multihoming, each web server on port 80 could have a different ACL.

Servlet Sandbox Functionality

The servlet sandbox will protect access to JavaServer resources such as these:

1. Files, including
   • Web pages served by JavaServer
   • Data used to operate each servlet
   • Other files on the file system
2. Runtime state, including
   • Threads controlled by other servlets
   • Security context of other servlets
   • Private Keys used to authenticate this server
3. Administrative state, including
   • Users and groups
   • ACL entries (including ones controlling the sandbox!)
4. Network Servers
5. Other resources controlled by SecurityManager objects

Top